The present invention relates to the fields of distributed computing systems, client-server computing and object-oriented programming. More specifically, the present invention teaches methods and apparatus for managing deactivation and shutdown of a server resident in a distributed object operating environment. Some specific server examples contemplated by the present invention include a computer process, a computer service including a collection of objects, or a single object.
Object oriented programming methodologies have received increasing attention over the past several years in response to the growing tendency for software developed using traditional programming methods to be delivered late and over budget. This stems from the fact that traditional programming techniques that emphasize procedural models and "linear" code tend to be difficult to design and maintain in many circumstances. Generally, large programs created using traditional methods are "brittle". That is, even small changes can effect numerous elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object oriented programming strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object's interface. Hence changes to the data and or procedures of the object are relatively isolated from the remainder of the program. This provides code that is more easily maintained as compared to code written using traditional methods, as changes to an object's code do not affect the code in the other objects. In addition, the inherent modular nature of objects and interfaces allows individual objects and interfaces to be reused in different programs. Thus, programmers can develop libraries of "tried and true" objects that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
A more recent advance in the field of object oriented methodologies has been the implementation of distributed object operating environments over computers interconnected via a computer network. As used herein, the term "distributed object" or "object" refers to an encapsulated package of code and data that can be manipulated by operations through an interface. Thus, distributed objects will be seen by those skilled in the art of object oriented programming (OOP) as including the basic properties that define traditional programming objects. However, distributed objects differ from traditional programming objects by the inclusion of two important features. First, distributed objects are multilingual. That is, the interfaces of distributed objects are defined using an interface definition language that can be mapped to a variety of different programming languages. One such interface definition language is Object Management Group's IDL. Second, distributed objects are location-independent, i.e., distributed objects can be located anywhere in a network. This contrasts sharply with traditional programming objects which typically exist in a single address space.
In general, distributed objects can be client objects or server objects, depending upon whether they are sending requests to other objects or replying to requests from clients. In a distributed object environment, requests and replies are made through an Object Request Broker (ORB) that is aware of the locations and status of the objects. One architecture which is suitable for implementing such an ORB is provided by the Common Object Request Broker Architecture (CORBA) specification. The CORBA specification was developed by the Object Management Group (OMG) to define the distributed computing environment world in terms of objects in a distributed client-server environment, where server objects are capable of providing services to clients requesting the service. In the following discussion, the terms "object" and "distributed object" will be used interchangeably.
Typically a server object can provide services to any entity which can request services. Therefore a client is defined herein as an entity requesting a service of an object. For example, a client may be an object residing in the same computer process as the server object or a computer process executing on a remote computer. In the preceding paragraphs we have termed an object providing service to a client a "server object." However, a more well known phrase for an object providing service to a client is "target object." Thus hereinafter the phrase "target object" will be used when the server under discussion is an object or a distributed object.
Elaborating further on the terminology of client-server interactions, a client will "call" a target object to "invoke" a "method" that is executed by the target object. Note that while "call" and "invoke" can carry slightly different meanings, herein the two terms are used interchangeably and their meanings will be understood from the context of the discussion herein. As is well known to those of skill in the art, a method is a procedure contained within an object which is made available to other entities, i.e. clients, for the purpose of requesting services of that object. Thus the object performing the service for the client is the server, hence the phrase client-server. In calling a method, the client may also pass those arguments, also referred to as parameters, necessary for the target object to perform the requested method. Please note that the previous term "method" is a term of the art of object oriented programming and differs from the term "method" classically used in drafting patent applications. However, for the sake of clarity, the phrases "operation" or "object operation" will be used in lieu of "method" hereinafter.
As will be appreciated by those skilled in the art of object oriented programming, target objects and can be thought of as resources available to clients. For example, an object could be a printer available to a multiplicity of clients in a computer network. The printer object may have operations such as "print document" or "shut down network connection." In turn, the printer object operations may require arguments such as "document type" (i.e. text, postscript, etc.), "quantity", "orientation", and "paper size." In another example, an object is a database object. The database object may have operations such as "read", "write", or "delete." The database object operations may require appropriate arguments such as "addressing", "password", or "format."
In normal situations (such as the printer object and the database object) resources can be shut down or otherwise made unavailable. By way of example, a printer object may be turned off thus becoming unavailable to clients. As another example, a database object might close to enable a data backup or a software upgrade. In a final example, an operating system may decide, based on a variety of criteria, that a specific object has outlived its usefulness and therefore should be eliminated. In each of these cases, as in any shut down scenario, there is a likelihood that clients are actively requesting services concurrent to the requested shut down.
Non-invasive shut-down and/or deactivation of a resource requires a sophisticated mechanism. One might imagine that orderly and predictable shutdown strategies are commonplace. However, this is not the case. Take, for example, the case of the printer object. Prior art for shutting down a printer includes an on/off power switch. When an operator (the client) of the printer turns the printer of, any print job (the requested service) is typically aborted immediately, resulting in a loss of print data and an unfinished print job.
Even advanced printing systems require a large degree of supplementary user support to perform a less than adequate service. Take for example, a Macintosh computer running under the Macintosh Operating System Version 7.5 printing to a standard laser printer. If the printer is turned off or becomes unavailable during the print job, the print job is aborted and the printing system displays a message to the computer user that the print job has aborted. This requires the operator to figure out and solve the problem (perhaps the computer administrator shutdown the network without warning) and then start the print job over. Or perhaps the Macintosh user wishes to shutdown the computer but the print job is still downloading data. The operating system warns the user and allows the user to (manually) either (1) terminate the print job, (2) perform the print job at a later time, or (3) leave the machine on until the print job is done.
The case of the database object is similar to that of the printer object. The prior art does not teach a shut down strategy which is non-invasive in regards to the services the database object provides to the database clients. For example, if a database object is shut down while a client is writing, data is lost and the state of the database and the state of the database client may no longer be consistent with one another.
The dilemmas of the aforementioned scenarios are commonplace in the multitude of computer applications having client-server interactions. Furthermore, effective, non-invasive resource shut down strategy is critical in systems wherein many of the features are intended to be fully automatic. In fact, in the aforementioned scenarios, the goal is to provide a fully automated service (such as printing) and this goal is not truly achieved. As is well understood by those skilled in the art of object oriented programming, the aforementioned modularity of objects makes the client-server interaction ubiquitous within the distributed object operating environment. Hence not having an orderly and predictable resource shut down strategy in a distributed object operating environment may be a handicap. What is needed is an orderly and predictable resource deactivation and/or shut down strategy. This strategy should be based on an underlying protocol which enables its use with a variety of different resources. It should be for use with all types of servers such as computer processes, services, and single objects. In particular, the shut down strategy must take advantage of the inherent qualities of objects to produce a generic solution for implementation across a large number of different types of objects.